The following is from Azure Administrator Training lab for AZ-103

Azure Networking Components

A major incentive for adopting cloud solutions such as Azure is to enableinformation technology (IT) departments to move server resources to thecloud. This can save money and simplify operations by removing the need tomaintain expensive datacenters with uninterruptible power supplies,generators, multiple fail-safes, clustered database servers, and so on. Forsmall and medium-sized companies, which might not have the expertise tomaintain their own robust infrastructure, moving to the cloud is particularlyappealing. Once the resources are moved to Azure, they require the same networkingfunctionality as an on-premises deployment, and in specific scenarios requiresome level of network isolation. Azure networking components offer a rangeof functionalities and services that can help organizations design and buildcloud infrastructure services that meet their requirements. Azure has manynetworking components.

Virtual Networks

An Azure Virtual Network (VNet) is a representation of your own network inthe cloud. It is a logical isolation of the Azure cloud dedicated to yoursubscription. You can use VNets to provision and manage virtual privatenetworks (VPNs) in Azure and, optionally, link the VNets with other VNets inAzure, or with your on-premises IT infrastructure to create hybrid or cross-premises solutions. Each VNet you create has its own CIDR block and can belinked to other VNets and on-premises networks if the CIDR blocks do notoverlap. You also have control of DNS server settings for VNets, andsegmentation of the VNet into subnets.

You can use virtual networks to:

• Create a dedicated private cloud-only VNet. Sometimes you don’trequire a cross-premises configuration for your solution. When youcreate a VNet, your services and VMs within your VNet cancommunicate directly and securely with each other in the cloud. You canstill configure endpoint connections for the VMs and services thatrequire internet communication, as part of your solution.
• Securely extend your data center With VNets. You can build traditionalsite-to-site (S2S) VPNs to securely scale your datacenter capacity. S2SVPNs use IPSEC to provide a secure connection between your corporateVPN gateway and Azure.
• Enable hybrid cloud scenarios. VNets give you the flexibility to supporta range of hybrid cloud scenarios. You can securely connect cloud-basedapplications to any type of on-premises system such as mainframes andUnix systems.

Subnets

A virtual network can be segmented into one or more subnets. Subnetsprovide logical divisions within your network. Subnets can help improvesecurity, increase performance, and make it easier to manage the network. Each subnet contains a range of IP addresses that fall within the virtualnetwork address space. Each subnet must have a unique address range,specified in CIDR format. The address range cannot overlap with othersubnets in the virtual network in the same subscription. It is important to carefully plan your subnets. Here are some things to thinkabout.

• Service requirements. Each service directly deployed into virtualnetwork has specific requirements for routing and the types of traffic thatmust be allowed into and out of subnets. A service may require, orcreate, their own subnet, so there must be enough unallocated space forthem to do so. For example, if you connect a virtual network to an on-premises network using an Azure VPN Gateway, the virtual networkmust have a dedicated subnet for the gateway.
• Virtual appliances. Azure routes network traffic between all subnets in avirtual network, by default. You can override Azure’s default routing toprevent Azure routing between subnets, or to route traffic betweensubnets through a network virtual appliance. So, if you require thattraffic between resources in the same virtual network flow through anetwork virtual appliance (NVA), deploy the resources to differentsubnets.
• Service endpoints. You can limit access to Azure resources such as anAzure storage account or Azure SQL database, to specific subnets with avirtual network service endpoint. Further, you can deny access to theresources from the internet. You may create multiple subnets, and enablea service endpoint for some subnets, but not others.
• Network security groups. You can associate zero or one networksecurity group to each subnet in a virtual network. You can associate thesame, or a different, network security group to each subnet. Eachnetwork security group contains rules, which allow or deny traffic to andfrom sources and destinations.

✔️ Azure reserves the first three IP addresses and the last IP address in eachsubnet address range.

Implementing Virtual Networks

You can create new virtual networks at any time. You can also add virtualnetworks when you create a virtual machine. Either way you will need todefine the address space, and at least one subnet. By default, you can createup to 50 virtual networks per subscription per region, although you canincrease this limit to 500 by contacting Azure support. ✔️ Default limits on Azure networking resources can change periodically soit’s a good idea to consult the documentation for the latest information.

✔️ Always plan to use an address space that is not already in use in yourorganization, either on-premises or in other VNets. Even if you plan for aVNet to be cloud-only, you may want to make a VPN connection to it later. Ifthere is any overlap in address spaces at that point, you will have toreconfigure or recreate the VNet. The next lesson will focus on IP addressing.

Multiple NICs in Virtual Machines

You can create virtual machines in Azure and attach multiple networkinterfaces (NICs) to each of your VMs. Having multiple NICs is a requirementfor many network virtual appliances, such as application delivery and WANoptimization solutions. Having multiple NICs also provides more networktraffic management functionality, including isolation of traffic between afront-end NIC and back-end NIC(s), or separation of data plane traffic frommanagement plane traffic.

The figure above shows a VM with three NICs, each connected to a differentsubnet.

• The order of the NICs from inside the VM will be random and could alsochange across Azure infrastructure updates. However, the IP addresses,and the corresponding ethernet MAC addresses will remain the same.For example, assume Eth1 has IP address 10.1.0.100 and MAC address00-0D-3A-B0-39-0D; after an Azure infrastructure update and reboot, itcould be changed to Eth2, but the IP and MAC pairing will remain thesame. When a restart is customer-initiated, the NIC order will remain thesame.
• The address for each NIC on each VM must be in a subnet and multipleNICs on a single VM can each be assigned addresses that are in thesame subnet.
• The VM size determines the number of NICS that you can create for aVM.

The following limitations are applicable when using the multiple NIC featureand availability sets:

• All VMs in an availability set need to use either multiple NICs or asingle NIC. You cannot have a mixture of multi NIC VMs and single NICVMs within an availability set. Same rules apply for VMs in a cloudservice.
• A VM with single NIC cannot be configured with multiple NICs (andvice-versa) once it is deployed, without deleting and re-creating it.

IP Addressing

IP Addressing

You can assign IP addresses to Azure resources to communicate with otherAzure resources, your on-premises network, and the Internet. There are twotypes of IP addresses you can use in Azure. Virtual networks can contain bothpublic and private IP address spaces.

1. Private IP addresses: Used for communication within an Azure virtualnetwork (VNet), and your on-premises network, when you use a VPNgateway or ExpressRoute circuit to extend your network to Azure.
2. Public IP addresses: Used for communication with the Internet,including Azure public-facing services.

IP addresses can also be statically assigned or dynamically assigned. StaticIP addresses do not change and are best for certain situations such as:

• DNS name resolution, where a change in the IP address would requireupdating host records.
• IP address-based security models which require apps or services to havea static IP address.
• SSL certificates linked to an IP address.
• Firewall rules that allow or deny traffic using IP address ranges.
• Role-based VMs such as Domain Controllers and DNS servers.

✔️ As a best practice you may decide to separate dynamically and staticallyassigned IP resources into different subnets. And, IP Addresses are nevermanaged from within a virtual machine.

Public IP Addresses

A public IP address resource can be associated with virtual machine networkinterfaces, internet-facing load balancers, VPN gateways, and applicationgateways. Azure can provide an IP address (dynamic assignment) or you canassign the IP address (static assignment). The type of resource affects theassignment.

Address SKUs When you create a public IP address you are given a SKU choice of either Basic or Standard.

Your SKU choice affects the IP assignment method, security, available resources, and redundancy. This table summarizes the differences.

Private IP Addresses

A private IP address resource can be associated with virtual machine networkinterfaces, internal load balancers, and application gateways. Azure canprovide an IP address (dynamic assignment) or you can assign the IP address (static assignment).

A private IP address is allocated from the address range of the virtualnetwork subnet a resource is deployed in.

• Dynamic. Azure assigns the next available unassigned or unreserved IPaddress in the subnet’s address range. For example, Azure assigns10.0.0.10 to a new resource, if addresses 10.0.0.4-10.0.0.9 are alreadyassigned to other resources. Dynamic is the default allocation method.
• Static. You select and assign any unassigned or unreserved IP address inthe subnet’s address range. For example, if a subnet’s address range is10.0.0.0/16 and addresses 10.0.0.4-10.0.0.9 are already assigned toother resources, you can assign any address between 10.0.0.10 -10.0.255.254.

Service Endpoints

A virtual network service endpoint provides the identity of your virtualnetwork to the Azure service. Once service endpoints are enabled in yourvirtual network, you can secure Azure service resources to your virtualnetwork by adding a virtual network rule to the resources. Today, Azure service traffic from a virtual network uses public IP addressesas source IP addresses. With service endpoints, service traffic switches to usevirtual network private addresses as the source IP addresses when accessingthe Azure service from a virtual network. This switch allows you to access theservices without the need for reserved, public IP addresses used in IPfirewalls.

Why use a service endpoint?

• Improved security for your Azure service resources. VNet privateaddress space can be overlapping and so, cannot be used to uniquelyidentify traffic originating from your VNet. Service endpoints provide theability to secure Azure service resources to your virtual network, byextending VNet identity to the service. Once service endpoints areenabled in your virtual network, you can secure Azure service resourcesto your virtual network by adding a virtual network rule to the resources.This provides improved security by fully removing public Internet accessto resources, and allowing traffic only from your virtual network.
• Optimal routing for Azure service traffic from your virtual network.Today, any routes in your virtual network that force Internet traffic toyour premises and/or virtual appliances, known as forced-tunneling, alsoforce Azure service traffic to take the same route as the Internet traffic.Service endpoints provide optimal routing for Azure traffic.
• Endpoints always take service traffic directly from your virtualnetwork to the service on the Microsoft Azure backbone network.Keeping traffic on the Azure backbone network allows you to continueauditing and monitoring outbound Internet traffic from your virtualnetworks, through forced-tunneling, without impacting service traffic.Learn more about user-defined routes and forced-tunneling.
• Simple to set up with less management overhead. You no longer needreserved, public IP addresses in your virtual networks to secure Azureresources through IP firewall. There are no NAT or gateway devicesrequired to set up the service endpoints. Service endpoints areconfigured through a simple click on a subnet. There is no additionaloverhead to maintaining the endpoints.

✔️ With service endpoints, the source IP addresses of the virtual machines inthe subnet for service traffic switches from using public IPv4 addresses tousing private IPv4 addresses. Existing Azure service firewall rules usingAzure public IP addresses will stop working with this switch. Please ensureAzure service firewall rules allow for this switch before setting up serviceendpoints. You may also experience temporary interruption to service trafficfrom this subnet while configuring service endpoints.

Service Endpoint Services

It is easy to add a service endpoint to the virtual network. Several services areavailable including: Azure Active Directory, Azure Cosmos DB, EventHub,KeyVault, Service Bus, SQL, and Storage.

Azure Storage. Generally available in all Azure regions. This endpoint givestraffic an optimal route to the Azure Storage service. Each storage accountsupports up to 100 virtual network rules.

Azure SQL Database and Azure SQL Data Warehouse. Generally availablein all Azure regions. A firewall security feature that controls whether thedatabase server for your single databases and elastic pool in Azure SQLDatabase or for your databases in SQL Data Warehouse acceptscommunications that are sent from particular subnets in virtual networks.

Azure Database for PostgreSQL server and MySQL. Generally available inAzure regions where database service is available. Virtual Network (VNet)services endpoints and rules extend the private address space of a VirtualNetwork to your Azure Database for PostgreSQL server and MySQL server.

Azure Cosmos DB. Generally available in all Azure regions. You canconfigure the Azure Cosmos account to allow access only from a specificsubnet of virtual network (VNet). By enabling Service endpoint to accessAzure Cosmos DB on the subnet within a virtual network, the traffic from thatsubnet is sent to Azure Cosmos DB with the identity of the subnet and VirtualNetwork. Once the Azure Cosmos DB service endpoint is enabled, you canlimit access to the subnet by adding it to your Azure Cosmos account.

Azure Key Vault. Generally available in all Azure regions. The virtualnetwork service endpoints for Azure Key Vault allow you to restrict access toa specified virtual network. The endpoints also allow you to restrict access toa list of IPv4 (internet protocol version 4) address ranges. Any userconnecting to your key vault from outside those sources is denied access.

Azure Service Bus and Azure Event Hubs. Generally available in all Azureregions. The integration of Service Bus with Virtual Network (VNet) serviceendpoints enables secure access to messaging capabilities from workloadslike virtual machines that are bound to virtual networks, with the networktraffic path being secured on both ends.

Azure Data Lake Store Gen 1. Generally available in all Azure regionswhere ADLS Gen1 is available. This feature helps to secure your Data LakeStorage account from external threats. ✔️ Adding service endpoints can take up to 15 minutes to complete. Eachservice endpoint integration has its own Azure documentation page.

Secure Access to Storage Endpoints

The steps necessary to restrict network access to Azure services varies acrossservices. For accessing a storage account, you would use the Firewalls andvirtual networks blade to add the virtual networks that will have access.Notice you can also configure to allow access to one or more public IPranges.

✔️ It is important to test and ensure the service endpoint is limiting access asexpected.

Azure DNS

Domains and Custom Domains

Initial domain name By default, when you create an Azure subscription an Azure AD domain iscreated for you. This instance of the domain has initial domain name in theform domainname.onmicrosoft.com. The initial domain name, while fullyfunctional, is intended primarily to be used as a bootstrapping mechanismuntil a custom domain name is verified.

Custom domain name Although the initial domain name for a directory can’t be changed or deleted,you can add any routable custom domain name you control. This simplifiesthe user sign-on experience by allowing user to logon with credentials theyare familiar with. For example, a contosogold.onmicrosoft.com, could beassigned a simpler custom domain name of contosogold.com.

Practical information about domain names

• Only a global administrator can perform domain management tasks inAzure AD, by default this is the user who created the subscription.
• Domain names in Azure AD are globally unique. If one Azure ADdirectory has verified a domain name, then no other Azure AD directorycan verify or use that same domain name.
• Before a custom domain name can be used by Azure AD, the customdomain name must be added to your directory and verified. This iscovered in the next topic.

For more information, you can see: Managing custom domain names in your Azure Active Directory –https://docs.microsoft.com/en-us/azure/active-directory/active-directory-domains-manage-azure-portal

Verifying Custom Domain Names

When an administrator adds a custom domain name to an Azure AD, it isinitially in an unverified state. Azure AD will not allow any directoryresources to use an unverified domain name. This ensures that only onedirectory can use a domain name, and the organization using the domainname owns that domain name. So, after adding the custom domain name, you must demonstrate ownershipof the domain name. This is called verification. and is done by adding a DNSrecord (MX or TXT) that is provided by Azure into your company’s DNS zone.Once this record is added, Azure will query the DNS domain for the presenceof the record. This could take several minutes or several hours. If Azureverifies the presence of the DNS record, it will then add the domain name tothe subscription.

✔️ Notice you can use a TXT or MX record.

Azure DNS Zones

Azure DNS provides a reliable, secure DNS service to manage and resolvedomain names in a virtual network without your needing to add a customDNS solution. A DNS zone hosts the DNS records for a domain. So, to start hosting yourdomain in Azure DNS, you need to create a DNS zone for that domain name.Each DNS record for your domain is then created inside this DNS zone. From the portal you can easily add a DNS zone and then view informationincluding name, number of records, resource group, location (always global),subscription, and name servers. When creating a DNS zone in Azure DNS remember:

• The name of the zone must be unique within the resource group, and thezone must not exist already.
• The same zone name can be reused in a different resource group or adifferent Azure subscription.
• Where multiple zones share the same name, each instance is assigneddifferent name server addresses.
• Only one set of addresses can be configured with the domain nameregistrar.

✔️ You do not have to own a domain name to create a DNS zone with thatdomain name in Azure DNS. However, you do need to own the domain toconfigure the domain. For more information, you can see: DNS Zones – https://docs.microsoft.com/en-us/azure/dns/dns-zones-records#dns-zones

DNS Record Sets

It’s important to understand the difference between DNS record sets and individual DNS records. A record set is a collection of records in a zone that have the same name and are the same type.

You can add up to 20 records to any record set. A record set cannot contain two identical records. Empty record sets (with zero records) can be created, but do not appear on the Azure DNS name servers. Record sets of type CNAME can contain one record at most. The Add record set page will change depending on the type of record you select. For an A record, you will need the TTL (Time to Live) and IP address.The time to live, or TTL, specifies how long each record is cached by clients before being requeried.

DNS Delegation

To delegate your domain to Azure DNS, you first need to know the nameserver names for your zone. Each time a DNS zone is created Azure DNSallocates name servers from a pool. Once the Name Servers are assigned,Azure DNS automatically creates authoritative NS records in your zone. The easiest way to see the name servers assigned to your zone is through theAzure portal. In this example, the zone ‘contoso.net’ has been assigned fourname servers: ‘ns1-01.azure-dns.com’, ‘ns2-01.azure-dns.net’, ‘ns3-01.azure-dns.org’, and ‘ns4-01.azure-dns.info’:

You can also discover the NS records with PowerShell, use Get-AzureRmDnsZone and Get-AzureRMDnsRecordSet. Note that the recordname “@” is used to refer to records at the apex of the zone.

# Retrieve the zone information $zone = Get-AzDnsZone –Name contoso.net –ResourceGroupName MyResourceGroup # Retrieve the name server records Get-AzDnsRecordSet –Name “@” –RecordType NS –Zone $zone

Once the DNS zone is created, and you have the name servers, you need toupdate the parent domain. Each registrar has their own DNS managementtools to change the name server records for a domain. In the registrar’s DNSmanagement page, edit the NS records and replace the NS records with theones Azure DNS created. ✔️ When delegating a domain to Azure DNS, you must use the name servernames provided by Azure DNS. You should always use all four name servernames, regardless of the name of your domain.

Child Domains If you want to set up a separate child zone, you can delegate a sub-domain inAzure DNS. For example, after configuring contoso.com in Azure DNS, youcould configure a separate child zone for partners.contoso.com. Setting up a sub-domain follows the same process as typical delegation. Theonly difference is that NS records must be created in the parent zonecontoso.com in Azure DNS, rather than in the domain registrar. The following PowerShell example demonstrates how this works. The samesteps can be executed via the Azure Portal, or via the cross-platform AzureCLI.

# Create the parent zone $parent = New-AzDnsZone -Name contoso.com -ResourceGroupName RG1 # Create the child zone $child = New-AzDnsZone -Name partners.contoso.com -ResourceGroupName RG1 # Retrieve NS records for the child zone $child_ns_recordset = Get-AzDnsRecordSet -Zone $child -Name "@" -RecordType NS # Create the NS record set in the parent zone. $parent_ns_recordset = New-AzDnsRecordSet -Zone $parent -Name "partners" -RecordType NS -Ttl 3600 $parent_ns_recordset.Records = $child_ns_recordset.Records Set-AzDnsRecordSet -RecordSet $parent_ns_recordset

✔️ The parent and child zones can be in the same or different resource group.Notice that the record set name in the parent zone matches the child zonename, in this case “partners”.

DNS for Private Domains

By using private DNS zones, you can use your own custom domain namesrather than the Azure-provided names available today. Using custom domainnames helps you to tailor your virtual network architecture to best suit yourorganization’s needs. It provides name resolution for virtual machines (VMs)within a virtual network and between virtual networks. Additionally, you canconfigure zones names with a split-horizon view, which allows a private and apublic DNS zone to share the name.

If you specify a registration virtual network, the DNS records for the VMsfrom that virtual network that are registered to the private zone are notviewable or retrievable from the Azure Powershell and Azure CLI APIs, butthe VM records are indeed registered and will resolve successfully. AzureDNS provides the many benefits:

• Removes the need for custom DNS solutions. Previously, manycustomers created custom DNS solutions to manage DNS zones in theirvirtual network. You can now perform DNS zone management by usingthe native Azure infrastructure, which removes the burden of creatingand managing custom DNS solutions.
• Use all common DNS records types. Azure DNS supports A, AAAA,CNAME, MX, PTR, SOA, SRV, and TXT records.
• Automatic hostname record management. Along with hosting yourcustom DNS records, Azure automatically maintains hostname recordsfor the VMs in the specified virtual networks. In this scenario, you canoptimize the domain names you use without needing to create customDNS solutions or modify applications.
• Hostname resolution between virtual networks. Unlike Azure-providedhost names, private DNS zones can be shared between virtual networks.This capability simplifies cross-network and service-discovery scenarios,such as virtual network peering.
• Familiar tools and user experience. To reduce the learning curve, thisnew offering uses well-established Azure DNS tools (PowerShell, AzureResource Manager templates, and the REST API).
• Split-horizon DNS support. With Azure DNS, you can create zones withthe same name that resolve to different answers from within a virtualnetwork and from the public internet. A typical scenario for split-horizonDNS is to provide a dedicated version of a service for use inside yourvirtual network.
• Available in all Azure regions. The Azure DNS private zones feature isavailable in all Azure regions in the Azure public cloud.

✔️ At the time of this writing, the Azure DNS Private Zone feature iscurrently in public preview. This preview version is provided without a servicelevel agreement, and is not recommended for production workloads.

Private Zones Scenarios

Scenario: Name resolution scoped to a single virtual network In this scenario, you have a virtual network in Azure that has a number ofAzure resources in it, including virtual machines (VMs). You want to resolvethe resources from within the virtual network via a specific domain name (DNS zone), and you need the name resolution to be private and notaccessible from the internet. Furthermore, for the VMs within the VNET, youneed Azure to automatically register them into the DNS zone.

In this scenario, VNET1 contains two VMs (VM1 and VM2). Each of theseVMs have Private IPs. So, if you create a Private Zone named contoso.comand link this virtual network as a Registration virtual network, Azure DNSwill automatically create two A records in the zone. Now, DNS queries fromVM1 to resolve VM2.contoso.com will receive a DNS response that containsthe Private IP of VM2. Furthermore, a Reverse DNS query (PTR) for thePrivate IP of VM1 (10.0.0.1) issued from VM2 will receive a DNS responsethat contains the FQDN of VM1, as expected.

Scenario: Name resolution for multiple networks Name resolution across multiple virtual networks is is probably the mostcommon usage for DNS private zones. The following diagram shows a simpleversion of this scenario where there are only two virtual networks – VNet1and VNet2.

• VNet1 is designated as a Registration virtual network and VNET2 isdesignated as a Resolution virtual network.
• The intent is for both virtual networks to share a common zonecontoso.com.
• The Resolution and Registration virtual networks are linked to the zone.
• DNS records for the Registration VNet VMs are automatically created.You can manually add DNS records for VMs in the Resolution virtualnetwork.

With this setup, you will observe the following behavior for forward andreverse DNS queries:

1. DNS queries across the virtual networks are resolved. A DNS queryfrom a VM in the Resolution VNet, for a VM in the Registration VNet,will receive a DNS response containing the Private IP of VM.
2. Reverse DNS queries are scoped to the same virtual network. AReverse DNS (PTR) query from a VM in the Resolution virtual network,for a VM in the Registration VNet, will receive a DNS responsecontaining the FQDN of the VM. But, a reverse DNS query from a VM inthe Resolution VNet, for a VM in the same VNet, will receiveNXDOMAIN.

✔️ There is also Split-Horizon functionality scenario.

Network Security Groups

Network Security Groups

You can limit network traffic to resources in a virtual network using a networksecurity group (NSG). A network security group contains a list of securityrules that allow or deny inbound or outbound network traffic. An NSG can beassociated to a subnet or a network interface.

Subnets You can assign NSGs to subnets and create protected screened subnets (alsocalled a DMZ). These NSGs can restrict traffic flow to all the machines thatreside within that subnet. Each subnet can have zero, or one, associatednetwork security groups.

Network Interfaces You can assign NSGs to a NIC so that all the traffic that flows through thatNIC is controlled by NSG rules. Each network interface that exists in a subnetcan have zero, or one, associated network security groups. Associations When you create an NSG the Overview blade provides information about theNSG such as, associated subnets, associated network interfaces, and securityrules.

✔️ Generally, this is used for specific VMs with Network Virtual Appliances (NVAs) roles, otherwise it is recommended to link NSG to the subnet level andre-use across your VNETs and subnets. For more information, you can see: Network Security Groups – https://docs.microsoft.com/en-us/azure/virtual-network/security-overview#network-security-groups

NSG Rules

Security rules in network security groups enable you to filter the type ofnetwork traffic that can flow in and out of virtual network subnets andnetwork interfaces. Azure creates several default security rules within eachnetwork security group. You can add more rules by specifying Name, Priority, Port, Protocol (Any,TCP, UDP), Source (Any, IP Addresses, Service tag), Destination (Any, IPAddresses, Virtual Network), and Action (Allow or Deny). You cannot deletethe default rules, but you can add other rules with a higher priority. Azurecreates the default rules in each network security group that you create. Youcannot remove the default rules, but you can override them by creating ruleswith higher priorities. There are three default inbound security rules. The rules deny all inboundtraffic except from the virtual network and Azure load balancers.

There are three default outbound security rules. The rules only allow outbound traffic to the Internet and the virtual network.

NSG Effective Rules

Be cautious when you want to apply NSG to both VM (NIC) and subnet levelat the same time. NSGs are evaluated independently, and an “allow” rule mustexist at both levels otherwise traffic will not be admitted.

In the above example if there was incoming traffic on port 80, you wouldneed to have the NSG at subnet level ALLOW port 80, and you would alsoneed another NSG with ALLOW rule on port 80 at the NIC level. Forincoming traffic, the NSG set at the subnet level is evaluated first, then theNSG set at the NIC level is evaluated. For outgoing traffic, it is the converse. If you have several NSGs and are not sure which security rules are beingapplied, you can use the Effective security rules link. For example, you couldverify the security rules being applied to a network interface.

Creating NSG Rules

It is easy to add inbound and outbound rules. There is a Basic and Advancedpage. The advanced option lets you select from a large variety of servicessuch as HTTPS, RDP, FTP, and DNS.

Service. The service specifies the destination protocol and port range for thisrule. You can choose a predefined service, like HTTPS and SSH. When youselect a service the Port range is automatically completed. Choose custom toprovide your own port range.

Port ranges. If you choose a custom service then provide a single port, suchas 80; a port range, such as 1024-65635; or a comma-separated list of singleports and/or port ranges, such as 80, 1024-65535. This specifies on whichports traffic will be allowed or denied by this rule. Provide an asterisk (*) toallow traffic on any port.

Priority. Rules are processed in priority order. The lower the number, thehigher the priority. We recommend leaving gaps between rules – 100, 200,300, etc. This is so it is easier to add new rules without editing existing rules.Enter a value between 100-4096 that is unique for all security rules within thenetwork security group.

References

https://github.com/MicrosoftLearning/AZ-103-MicrosoftAzureAdministrator